The third generation partnership project, 3GPP, is currently working on specifying support for MP HSDPA (Multi-Point High-Speed Downlink Packet Access) in Release-11. When MP HSDPA is employed, downlink data is sent to UE (User Equipment, also referred to as mobile/wireless terminal) via two instead of one NodeB (herein also referred to as radio base station, RBS). The UE will thus receive data via two MAC-hs (HSDPA Medium Access Control protocol handling fixed size RLC data) or MAC-ehs (HSDPA Medium Access Control protocol handling fixed or flexible sized RLC data) flows and re-order data on RLC (Radio Link Control) level for delivery to higher layers. It should be noted that various terminology has been used to describe this functionality in 3GPP such as HSDPA Multipoint Transmission, Inter-NodeB Multi-Point Transmissions and HSDPA Multiflow data but the abbreviation MP HSDPA will henceforth be used to describe this functionality.
A potential problem with some existing MP HSDPA solutions is that since data in the UE may be received from more than one NodeB, then the data as delivered to the RLC layer in UE may be out of order. Since the RLC layer in UE will trigger a status report when missing RLC SN (Sequence Number) is detected, this will lead to unnecessary RLC retransmissions if the missing data has already been sent to the other NodeB but not yet transmitted to UE. The unnecessary retransmissions this will cause will in turn result in that one or both NodeBs will buffer and eventually transmit redundant data to the UE.
Various solutions to this problem on RLC level have been suggested as outlined in 3GPP reference R2-113299, “Layer 2 considerations for Inter-Node Multipoint HSDPA operation”, but these may not reduce/eliminate the problem of redundant data. To this it can be added that in a MP HSDPA there may even be multiple copies of the same MAC-d (Medium Access Control protocol handling dedicated data) PDUs (Protocol Data Units) in one or both NodeB PQs (Priority Queues) since the UE may via RLC status reports sent requests for additional retransmissions for data already queued in the NodeB but not yet transmitted.
Although this may not necessarily cause a protocol failure, it is detrimental in that it can lead to an inefficient use of available air interface resources in existing solutions because this redundant data may need to be sent to UE before it is discarded.